Well one of the things you should have noticed if you let the program run long enough, the speed of the ball just keep increasing. There does not seem to be an upper limit. In fact there is not. After a certain speed though the bouncing of the ball becomes much less convincing and the graphic effect is not very pleasing. What we need to is to enforce a speed limit. Although the balls speed seems to increase rather than decrease, we should have both an upper and lower limit.

We can do this by introducing a couple simple IF-THEN statements. One will say if xchg is less than a certain value, make some other value. The other will say that if xchg is greater than some certain value, make it this other value. I chose 8 for the low end and 26 for the upper end. Here is the code:

    if xchg < 8 then xchg = 8
    if xchg > 26 then xchg = 26

Make sure you insert this just before the code that resets the xchg polarity, so that the code block looks like this now:

[changedirection]
    ballspeed = int(rnd(0)*4)-1
    direction = -1
    if xchg < 0 then direction = 1
    xchg = abs(xchg)    
    xchg = xchg + ballspeed
    if xchg < 8 then xchg = 8
    if xchg > 26 then xchg = 26
    xchg = xchg * direction
    wait

Now the ball will mind its speed! Have a go and see - huh?

Well that leaves us with the second item we wanted to accomplish when the ball hit a side wall - and that was introducing a little variability into the ychg value so that the balls movement would be a bit more random. The code will be almost identical to the code we just developed for xchg and ballspeed and it will follow that code. Remember the three things we did: 1) determine the direction and store it (with the correct future polarity), 2) take the absolute value of ychg and add a random factor to it, 3) apply the correct polarity to the balls motion. We developed that code in detail in the paragraphs above. Let me simply show you the code. For this to work remove the WAIT statement that currently is at the end of the "[changedirection]" code block.

    direction = 1
    if ychg < 0 then direction = -1

That code determined the correct direction (and there for future polarity) of ychg.

    ychg = abs(ychg)
    ychg = ychg + ((int(rnd(0)*9)-3) / (int(rnd(0)*3)+1))

This code sets ychg to the absolute value of itself and then adds a random factor to it. It is potentially a decimal value, not always a whole number. That will not be a problem for the program though. I developed that factor a long time ago, I suppose you could figure it out, but is seems to create whole and fractional numbers between -3 and positive 6. Numbers around zero and 1 seem to be popular.

Although not mentioned in the three steps, we found out that we need to control the upper and lower bounds of the xchg (ball speed) and ychg is no different. So, we add the following code to insure that the angle of deflection of the ball never gets too far out of hand:

    if ychg < 0 then ychg = 0
    if ychg > 10 then ychg = 11.25

Finally we apply the directional polarity to the value of ychg:

    ychg = ychg * direction

Don't forget to end it with a wait statement.

   wait

The entire section should now look pretty much like this:

[changedirection]
    ballspeed = int(rnd(0)*4)-1
    direction = -1
    if xchg < 0 then direction = 1
    xchg = abs(xchg)    
    xchg = xchg + ballspeed
    if xchg < 8 then xchg = 8
    if xchg > 26 then xchg = 26
    xchg = xchg * direction

    direction = 1
    if ychg < 0 then direction = -1
    ychg = abs(ychg)
    ychg = ychg + ((int(rnd(0)*9)-3) / (int(rnd(0)*3)+1))
    if ychg < 0 then ychg = 0
    if ychg > 10 then ychg = 11.25
    ychg = ychg * direction
    
    wait

Go ahead and click RUN and play around with it.

That pretty much finishes the bouncing ball off. The entire program to this point is listed in Appendix B. Note that I have added comments, adjusted a couple parameters, fixed a rare bug and added a couple tracking fields that show ball speed and angle of deflection. Check it out! I want to develop this just a bit more, bit we have covered so much ground with this installment, we will need to wait until next time.

We will be adding a paddle, reading keystrokes from the keyboard, moving the paddle and finally introducing sprites as an easier alternative to game graphics. If you are looking for a challenge (and I hope you are!), please try adding a paddle on the right side of the game area. I have set my version up to use the "L" and "P" keys to operate the paddle. I use a new event that is only supported by the graphicbox (or graphic window) called the "when event" which is triggering on the "character input" event. It can be a little trick to get the hang of to start, but is really easy to work with once you get to know it. You can get a head start by studying up on it in the helpfile. Here is a snippet to get you started:

The helpfile recommend that you "See also: Graphics, Inkey$, Using Virtual Key Contants wiht Inkey$., Using Inkey$, Reading Mouse Events and Keystrokes" - and I also recommend that.

See if you can figure out how to get a paddle running in your program. Here is a screen shot of my version of the program running:

Until next time, happy coding!